home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000036_owner-urn-ietf _Thu Oct 10 01:59:10 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA08570 for urn-ietf-out; Thu, 10 Oct 1996 01:59:10 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA08565 for <urn-ietf@services.bunyip.com>; Thu, 10 Oct 1996 01:59:08 -0400
  3. Received: from shell1.aimnet.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA02849  (mail destined for urn-ietf@services.bunyip.com); Thu, 10 Oct 96 01:59:06 -0400
  5. Received: (from dwm@localhost) by shell1.aimnet.com (8.7.3/SHELL) id WAA08247; Wed, 9 Oct 1996 22:59:04 -0700 (PDT)
  6. Date: Wed, 9 Oct 1996 22:59:02 -0700 (PDT)
  7. From: "David W. Morris" <dwm@xpasc.com>
  8. X-Sender: dwm@shell1.aimnet.com
  9. To: urn-ietf@bunyip.com
  10. Subject: Re: [URN] advantages of NAPTR over PURLs
  11. In-Reply-To: <96Oct9.223036pdt."2764"@golden.parc.xerox.com>
  12. Message-Id: <Pine.SOL.3.91.961009225537.5115B-100000@shell1.aimnet.com>
  13. Mime-Version: 1.0
  14. Content-Type: TEXT/PLAIN; charset=US-ASCII
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: "David W. Morris" <dwm@xpasc.com>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20.  
  21. On Wed, 9 Oct 1996, Larry Masinter wrote:
  22.  
  23. > > One point though: adminisration and security are two things you do AFTER
  24. > > you have a system that can scale and function. If you don't have 
  25. > > something that works then all the security and administration in the
  26. > > world won't get you squat.
  27. > 
  28. > This just doesn't hold water. Most of the issues we have to deal with
  29. > in 'scalability' are administration and security. We can't design
  30. > protocols that way any more. It is completely unacceptable that after
  31. > three years of talking about URNs and meeting about URNs that the
  32. > first 'URN implementation' doesn't have a credible story about
  33. > administration and security.
  34.  
  35. My response was a lot less polite than Larry's. Operational scalability
  36. is the whole problem. If we are not to worry about administaration and
  37. security, there is no point to URNs ... URLs scale just fine ... but
  38. they are hell to administer when one gets down to little issues like
  39. persistence.
  40.  
  41. Dave Morris